Embodiments of the inventive subject matter generally relate to the field of computer systems, and, more particularly, to trusted computer source code escrow.
Commercial closed source software typically has the limitation that it is built and compiled for a target platform and is constrained to whatever platform the compiler at the time the source code is compiled was targeted for. This means a compiled Intel x86 binary will not run on a Power system. Alternatively, in the case of new revisions of an existing architecture the compiler uses whatever platform features are available at the time. This generally results in binary code that does not utilize features unique to platforms that appear subsequent to the time the source code was compiled. When a customer wants to purchase new servers, whether it's a whole new architecture (i.e. moving from an Intel x86 architecture to Power) or a new revision of the same architecture (i.e. moving from Power6 to Power7), there is an inherent problem with what to do with the existing software and workloads. Traditionally customers are forced to purchase new software and perform any migration and conversions of application data necessary to utilize the new software, if indeed it is available.
Another issue is that software is built using compiling options designed for a general audience, attempting to satisfy the needs of the widest scope of customers. This will exclude some customers from implementing an optimized solution when a simple re-compile could produce an application tailored to the hardware or software environment actually used by the customer.
A further issue arises when a software supplier no longer supports a product, be it ‘end of life’ or indeed the supplier is no longer in business. In such cases the customer can get stuck with software which only runs on legacy platforms where important updates such as security fixes are no longer available. The traditional approach to this is to use a source code escrow, where the supplier will hold the source code for a product in escrow with a third party in the event it needs to be retrieved at a later date given certain triggers in the agreement with the customer. This traditional approach has many shortcomings. First, the cost of writing up legal agreements for each customer's needs and holding software source code in escrow is very expensive with recurring costs not to mention time consuming and complicated. Second, the source code is not available to customers until a worst case scenario, as it will contain trade secrets which will be exposed as soon as the customer takes possession of the source code. Third, there is no guarantee the customer can actually do anything with the source code without spending a great deal of time, effort and money to utilize it.